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Abstract 


Presence and Instant Messaging have recently emerged as a new medium 
of communications over the Internet. Presence is a means for 
finding, retrieving, and subscribing to changes in the presence 
information (e.g. "online" or "offline") of other users. Instant 
messaging is a means for sending small, simple messages that are 
delivered immediately to online users. 


Applications of presence and instant messaging currently use 
independent, non-standard and non-interoperable protocols developed 
by various vendors. The goal of the Instant Messaging and Presence 
Protocol (IMPP) Working Group is to define a standard protocol so 
that independently developed applications of instant messaging and/or 
presence can interoperate across the Internet. This document defines 
a minimal set of requirements that IMPP must meet. 
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Les 


Terminology 


The following terms are defined in [RFC 2778] and are used with those 
definitions in this document: 


ACCESS RULES 
CLOSED 

FETCHER 

INSTANT INBOX 
INSTANT MESSAGE 
NOTIFICATION 
OPEN 

POLLER 

PRESENCE INFORMATION 
PRESENCE SERVICE 
PRESENTITY 
PRINCIPAL 

PROXY 

SERVER 

STATUS 
SUBSCRIBER 
SUBSCRIPTION 
WATCHER 


The terms MUST and SHOULD are used in the following sense while 
specifying requirements: 


MUST: A proposed solution will have to meet this requirement. 
SHOULD: A proposed solution may choose not to meet this requirement. 


Note that this usage of MUST and SHOULD differs from that of RFC 
2119; 


Additionally, the following terms are used in this document and 
defined here: 


ADMINISTRATOR: A PRINCIPAL with authority over local computer and 
network resources, who manages local DOMAINS or FIREWALLS. For 
security and other purposes, an ADMINISTRATOR often needs or wants to 
impose restrictions on network usage based on traffic type, content, 
volume, or endpoints. A PRINCIPAL’s ADMINISTRATOR has authority over 
some or all of that PRINCIPAL’s computer and network resources. 


DOMAIN: A portion of a NAMESPACE. 


ENTITY: Any of PRESENTITY, SUBSCRIBER, FETCHER, POLLER, or WATCHER 
(all defined in [RFC 2778]). 
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FIREWALL: A point of administrative control over connectivity. 
Depending on the policies being enforced, parties may need to take 
unusual measures to establish communications through the FIREWALL. 


IDENTIFIER: A means of indicating a point of contact, intended for 
public use such as on a business card. Telephone numbers, email 
addresses, and typical home page URLs are all examples of IDENTIFIERS 
in other systems. Numeric IP addresses like 10.0.0.26 are not, and 
neither are URLs containing numerous CGI parameters or long arbitrary 
identifiers. 


INTENDED RECIPIENT: The PRINCIPAL to whom the sender of an INSTANT 
MESSAGE is sending it. 


NAMESPACE: The system that maps from a name of an ENTITY to the 
concrete implementation of that ENTITY. A NAMESPACE may be composed 
of a number of distinct DOMAINS. 


OUT OF CONTACT: A situation in which some ENTITY and the PRESENCE 
SERVICE cannot communicate. 


SUCCESSFUL DELIVERY: A situation in which an INSTANT MESSAGE was 
transmitted to an INSTANT INBOX for the INTENDED RECIPIENT, and the 
INSTANT INBOX acknowledged its receipt. SUCCESSFUL DELIVERY usually 
also implies that an INBOX USER AGENT has handled the message in a 
way chosen by the PRINCIPAL. However, SUCCESSFUL DELIVERY does not 
imply that the message was actually seen by that PRINCIPAL. 


2. Shared Requirements 


This section describes non-security requirements that are common to 
both an PRESENCE SERVICE and an INSTANT MESSAGE SERVICE. Section 6 
describes requirements specific to a PRESENCE SERVICE, while Section 
7 describes requirements specific to an INSTANT MESSAGE SERVICE. 
Section 8 describes security considerations. The reader should note 
that Section 11 is an appendix that provides historical context and 
aids in tracing the origins of requirements in Section 8. Section 11 
is not, however, a statement of current IMPP requirements. 


It is expected that Presence and Instant Messaging services will be 
particularly valuable to users over mobile IP wireless access 
devices. Indeed the number of devices connected to the Internet via 
wireless means is expected to grow substantially in the coming years. 
It is not reasonable to assume that separate protocols will be 
available for the wireless portions of the Internet. In addition, we 
note that wireless infrastructure is maturing rapidly; the work 
undertaken by this group should take into account the expected state 
of the maturity of the technology in the time-frame in which the 
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Presence and Instant Messaging protocols are expected to be deployed. 


To this end, the protocols designed by this Working Group must be 
suitable for operation in a context typically associated with mobile 
wireless access devices, viz. high latency, low bandwidth and 
possibly intermittent connectivity (which lead to a desire to 
minimize round-trip delays), modest computing power, battery 
constraints, small displays, etc. In particular, the protocols must 
be designed to be reasonably efficient for small payloads. 


2.1. Namespace and Administration 
2.1.1. The protocols MUST allow a PRESENCE SERVICE to be available 


independent of whether an INSTANT MESSAGE SERVICE is available, and 
vice-versa. 


2.1.2. The protocols must not assume that an INSTANT INBOX is 
necessarily reached by the same IDENTIFIER as that of a PRESENTITY. 
Specifically, the protocols must assume that some INSTANT INBOXes may 
have no associated PRESENTITIES, and vice versa. 


2.1.3. The protocols MUST also allow an INSTANT INBOX to be reached 
via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY. 


2.1.4. The administration and naming of ENTITIES within a given 
DOMAIN MUST be able to operate independently of actions in any other 
DOMAIN. 


2.1.5. The protocol MUST allow for an arbitrary number of DOMAINS 
within the NAMESPACE. 


2.2. Scalability 
2.2.1. It MUST be possible for ENTITIES in one DOMAIN to interoperate 
with ENTITIES in another DOMAIN, without the DOMAINS having 


previously been aware of each other. 


The protocol MUST be capable of meeting its other functional and 
performance requirements even when 


== (2.2.2) there are millions of ENTITIES within a single DOMAIN. 


-- (2.2.3) there are millions of DOMAINS within the single 
NAMESPACE. 
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-- (2.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to hundreds 
of PRESENTITIES. 


== (2.2.5) hundreds of distinct SUBSCRIBERS have SUBSCRIPTIONS to 
a single PRESENTITY. 


-=- (2.2.6) every single SUBSCRIBER has SUBSCRIPTIONS to 
PRESENTITIES in hundreds of distinct DOMAINS. 


These are protocol design goals; implementations may choose to place 
lower limits. 


2.3. Access Control 
The PRINCIPAL controlling a PRESENTITY MUST be able to control 


—— (2.3.1) which WATCHERS can observe that PRESENTITY’s PRESENCE 
INFORMATION. 


-- (2.3.2) which WATCHERS can have SUBSCRIPTIONS to that 
PRESENTITY’s PRESENCE INFORMATION. 


-- (2.3.3) what PRESENCE INFORMATION a particular WATCHER will see 
for that PRESENTITY, regardless of whether the WATCHER gets it 
by fetching or NOTIFICATION. 


== (2.3.4) which other PRINCIPALS, if any, can update the PRESENCE 
INFORMATION of that PRESENTITY. 


The PRINCIPAL controlling an INSTANT INBOX MUST be able to control 


-=- (2.3.5) which other PRINCIPALS, if any, can send INSTANT 
MESSAGES to that INSTANT INBOX. 


-=- (2.3.6) which other PRINCIPALS, if any, can read INSTANT 
MESSAGES from that INSTANT INBOX. 


2.3.7. Access control MUST be independent of presence: the PRESENCE 
SERVICE MUST be able to make access control decisions even when the 
PRESENTITY is OUT OF CONTACT. 


2.4. Network Topology 


Note that intermediaries such as PROXIES may be necessitated between 
IP and non-IP networks, and by an end-user’s desire to provide 
anonymity and hide their IP address. 
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2.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both 
directly and via intermediaries, such as PROXIES. 


2.4.2. The protocol MUST allow the sending of a NOTIFICATION both 
directly and via intermediaries, such as PROXIES. 


2.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both 
directly and via intermediaries, such as PROXIES. 


2.4.4. The protocol proxying facilities and transport practices MUST 
allow ADMINISTRATORS ways to enable and disable protocol activity 
through existing and commonly-deployed FIREWALLS. The protocol MUST 
specify how it can be effectively filtered by such FIREWALLS. 


2.5. Message Encryption and Authentication 


2.5.1. The protocol MUST provide means to ensure confidence that a 
received message (NOTIFICATION or INSTANT MESSAGE) has not been 
corrupted or tampered with. 


2.5.2. The protocol MUST provide means to ensure confidence that a 
received message (NOTIFICATION or INSTANT MESSAGE) has not been 
recorded and played back by an adversary. 


2.5.3. The protocol MUST provide means to ensure that a sent message 
(NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that 
the sender allows. 


2.5.4. The protocol MUST allow any client to use the means to ensure 
non-corruption, non-playback, and privacy, but the protocol MUST NOT 
require that all clients use these means at all times. 

3. Additional Requirements for PRESENCE INFORMATION 
The requirements in section 6 are applicable only to PRESENCE 
INFORMATION and not to INSTANT MESSAGES. Additional constraints on 
PRESENCE INFORMATION in a system supporting INSTANT MESSAGES appear 
in Section 7.4. 


3.1. Common Presence Format 


3.1.1. All ENTITIES MUST produce and consume at least a common base 
format for PRESENCE INFORMATION. 


3.1.2. The common presence format MUST include a means to uniquely 
identify the PRESENTITY whose PRESENCE INFORMATION is reported. 
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3.1.3. The common presence format MUST include a means to encapsulate 
contact information for the PRESENTITY’s PRINCIPAL (if applicable), 
such as email address, telephone number, postal address, or the like. 


3.1.4. There MUST be a means of extending the common presence format 
to represent additional information not included in the common 
format, without undermining or rendering invalid the fields of the 
common format. 


3.1.5. The working group must define the extension and registration 
mechanisms for presence information schema, including new STATUS 
conditions and new forms for OTHER PRESENCE MARKUP. 


3.1.6. The presence format SHOULD be based on IETF standards such as 
vCard [RFC 2426] if possible. 


3.2. Presence Lookup and Notification 


3.2.1. A FETCHER MUST be able to fetch a PRESENTITY’s PRESENCE 
INFORMATION even when the PRESENTITY is OUT OF CONTACT. 


3.2.2. A SUBSCRIBER MUST be able to request a SUBSCRIPTION to a 
PRESENTITY’s PRESENCE INFORMATION, even when the PRESENTITY is OUT OF 
CONTACT. 


3.2.3. If the PRESENCE SERVICE has SUBSCRIPTIONS for a PRESENTITY’s 
PRESENCE INFORMATION, and that PRESENCE INFORMATION changes, the 
PRESENCE SERVICE MUST deliver a NOTIFICATION to each SUBSCRIBER, 
unless prevented by the PRESENTITY’s ACCESS RULES. 


3.2.4. The protocol MUST provide a mechanism for detecting when a 
PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT. 


3.2.5. The protocol MUST NOT depend on a PRESENTITY or SUBSCRIBER 
gracefully telling the service that it will no longer be in 
communication, since a PRESENTITY or SUBSCRIBER may go OUT OF CONTACT 
due to unanticipated failures. 


3.3. Presence Caching and Replication 


3.3.1. The protocol MUST include mechanisms to allow PRESENCE 
INFORMATION to be cached. 


3.3.2. The protocol MUST include mechanisms to allow cached PRESENCE 
INFORMATION to be updated when the master copy changes. 
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3.3.3 The protocol caching facilities MUST NOT circumvent established 
ACCESS RULES or restrict choice of authentication/encryption 
mechanisms. 


3.4 Performance 


4. 


de 


3.4.1 When a PRESENTITY changes its PRESENCE INFORMATION, any 
SUBSCRIBER to that information MUST be notified of the changed 
information rapidly, except when such notification is entirely 
prevented by ACCESS RULES. This requirement is met if each 
SUBSCRIBER’s NOTIFICATION is transported as rapidly as an INSTANT 
MESSAGE would be transported to an INSTANT INBOX. 


Additional Requirements for INSTANT MESSAGES 


The requirements in section 4 are applicable only to INSTANT MESSAGES 
and not to PRESENCE INFORMATION, with the exception of Section 4.4. 
Section 4.4 describes constraints on PRESENCE INFORMATION that are 
relevant only to systems that support both INSTANT MESSAGES and 
PRESENCE INFORMATION. 


Common Message Format 


4.1.1. All ENTITIES sending and receiving INSTANT MESSAGES MUST 
implement at least a common base format for INSTANT MESSAGES. 


4.1.2. The common base format for an INSTANT MESSAGE MUST identify 
the sender and intended recipient. 


4.1.3. The common message format MUST include a return address for 
the receiver to reply to the sender with another INSTANT MESSAGE. 


4.1.4. The common message format SHOULD include standard forms of 
addresses or contact means for media other than INSTANT MESSAGES, 
such as telephone numbers or email addresses. 


4.1.5. The common message format MUST permit the encoding and 
identification of the message payload to allow for non-ASCII or 
encrypted content. 


4.1.6. The protocol must reflect best current practices related to 
internationalization. 


4.1.7. The protocol must reflect best current practices related to 
accessibility. 
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4.1.8. The working group MUST define the extension and registration 
mechanisms for the message format, including new fields and new 
schemes for INSTANT INBOX ADDRESSES. 


4.1.9. The working group MUST determine whether the common message 
format includes fields for numbering or identifying messages. If 
there are such fields, the working group MUST define the scope within 
which such identifiers are unique and the acceptable means of 
generating such identifiers. 


4.1.10. The common message format SHOULD be based on IETF-standard 
MIME [RFC 2045]. 


4.2. Reliability 


4.2.1. The protocol MUST include mechanisms so that a sender can be 
informed of the SUCCESSFUL DELIVERY of an INSTANT MESSAGE or reasons 
for failure. The working group must determine what mechanisms apply 
when final delivery status is unknown, such as when a message is 
relayed to non-IMPP systems. 


4.3 Performance 


4.3.1. The transport of INSTANT MESSAGES MUST be sufficiently rapid 
to allow for comfortable conversational exchanges of short messages. 


4.4 Presence Format 


4.4.1. The common presence format MUST define a minimum standard 
presence schema suitable for INSTANT MESSAGE SERVICES. 


4.4.2. When used in a system supporting INSTANT MESSAGES, the common 
presence format MUST include a means to represent the STATUS 
conditions OPEN and CLOSED. 


4.4.3. The STATUS conditions OPEN and CLOSED may also be applied to 
messaging or communication modes other than INSTANT MESSAGE SERVICES. 
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5. Security Considerations 


Security considerations are addressed in section 2.3, Access Control, 
and section 2.5, Message authentication and encryption. 


This section describes further security-related requirements that the 
protocol must meet. 


The security requirements were derived from a set of all-encompassing 
"security expectations" that were then evaluated for practicality and 
implementability and translated into requirements. In the appendix, 
we describe the expectations and the process used to transform them 
into requirements. In this section, we simply list the consolidated 
set of derived requirements. 


Note that in the requirements, ADMINISTRATORs may have privileges 
beyond those allowed to PRINCIPALs referred to in the requirements. 
(Unless otherwise noted, the individual expectations specifically 
refer to PRINCIPALS.) It is up to individual implementations to 
control administrative access and implement the security privileges 
of ADMINISTRATORs without compromising the requirements made on 
PRINCIPALS. 


Unless noted otherwise, A,B,C are all names of non-ADMINISTRATOR 
PRINCIPALS. 


5.1. Requirements related to SUBSCRIPTIONS 
When A establishes a SUBSCRIPTION to B’s PRESENCE INFORMATION: 


5.1.1. The protocol MUST provide A means of identifying and 
authenticating that the PRESENTITY subscribed to is controlled by B. 


5.1.2. If A so chooses, the protocol SHOULD NOT make A’s SUBSCRIPTION 
to B obvious to a third party C. 


5.1.3. The protocol MUST provide B with means of allowing an 
unauthenticated subscription by A. 


5.1.4. The protocol MUST provide A means of verifying the accurate 
receipt of the content B chooses to disclose to A. 


5.1.5. B MUST inform A if B refuses A's SUBSCRIPTION. Note that B may 
choose to accept A's SUBSCRIPTION, but fail to deliver any 
information to it (so-called "polite blocking"). See 5.1.15. 


5.1.6. The protocol MUST NOT let any third party C force A to 
subscribe to B’s PRESENCE INFORMATION without A’s consent. 
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5.1.7. A MUST be able to cancel her SUBSCRIPTION to B’s PRESENCE 
INFORMATION at any time and for any reason. When A does so, the 
PRESENCE SERVICE stops informing A of changes to B’s PRESENCE 
INFORMATION. 


5.1.8. The protocol MUST NOT let an unauthorized party C cancel A’s 
SUBSCRIPTION to B. 


5.1.9. If A’s SUBSCRIPTION to B is cancelled, the service SHOULD 
inform A of the cancellation. 


5.1.10. A SHOULD be able to determine the status of A’s SUBSCRIPTION 
to B, at any time. 


5.1.11. The protocol MUST provide B means of learning about A’s 
SUBSCRIPTION to B, both at the time of establishing the SUBSCRIPTION 
and afterwards. 


5.1.12. The protocol MUST provide B means of identifying and 
authenticating the SUBSCRIBER’s PRINCIPAL, A. 


5.1.13. It MUST be possible for B to prevent any particular PRINCIPAL 
from subscribing. 


5.1.14. It MUST be possible for B to prevent anonymous PRINCIPALS 
from subscribing. 


5.1.15. It MUST be possible for B to configure the PRESENCE SERVICE 
to deny A’s subscription while appearing to A as if the subscription 
has been granted (this is sometimes called "polite blocking"). The 
protocol MUST NOT mandate the PRESENCE SERVICE to service 
subscriptions that are treated in this manner. 


5.1.16. B MUST be able to cancel A’s subscription at will. 


5.1.17. The protocol MUST NOT require A to reveal A’s IP address to 
By 


5.1.18 The protocol MUST NOT require B to reveal B’s IP address to A. 
5.2. Requirements related to NOTIFICATION 


When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to 
another PRINCIPAL A: 


5.2.1. The protocol MUST provide means of ensuring that only the 


PRINCIPAL A being sent the NOTIFICATION by B can read the 
NOTIFICATION. 
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5.2.2. A should receive all NOTIFICATIONS intended for her. 

5.2.3. It MUST be possible for B to prevent A from receiving 
notifications, even if A is ordinarily permitted to see such 
notifications. It MUST be possible for B to, at its choosing, notify 
different subscribers differently, through different notification 
mechanisms or through publishing different content. This is a 
variation on "polite blocking". 


5.2.4. The protocol MUST provide means of protecting B from another 
PRINCIPAL C "spoofing" notification messages about B. 


5.2.5. The protocol MUST NOT require that A reveal A’s IP address to 
5.2.6. The protocol MUST NOT require that B reveal B’s IP address to 
A. 

5.3. Requirements related to receiving a NOTIFICATION 


When a PRINCIPAL A receives a notification message from another 
principal B, conveying PRESENCE INFORMATION, 


5.3.1. The protocol MUST provide A means of verifying that the 
presence information is accurate, as sent by B. 


5.3.2. The protocol MUST ensure that A is only sent NOTIFICATIONS 
from entities she has subscribed to. 


5.3.3. The protocol MUST provide A means of verifying that the 
notification was sent by B. 


5.4. Requirements related to INSTANT MESSAGES 
When a user A sends an INSTANT MESSAGE M to another user B, 
5.4.1. A MUST receive confirmation of non-delivery. 
5.4.2. If M is delivered, B MUST receive the message only once. 


5.4.3. The protocol MUST provide B means of verifying that A sent the 
message. 


5.4.4. B MUST be able to reply to the message via another instant 
message. 


5.4.5. The protocol MUST NOT always require A to reveal A’s IP 
address, for A to send an instant message. 
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5.4.6. The protocol MUST provide A means of ensuring that no other 
PRINCIPAL C can see the content of M. 

5.4.7. The protocol MUST provide A means of ensuring that no other 
PRINCIPAL C can tamper with M, and B means to verify that no 
tampering has occurred. 


5.4.8. B must be able to read M. 


5.4.9. The protocol MUST allow A to sign the message, using existing 
standards for digital signatures. 


5.4.10. B MUST be able to prevent A from sending him messages 
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8. Appendix: Security Expectations and Deriving Requirements 


This appendix is based on the security expectations discussed on the 
impp mailing list and assembled by Jesse Vincent. The original form 
of numbering has been preserved in this appendix (so there are 
several different items labeled Bl, for example). The derived 
requirements have new numbers that are consistent with the main body 
of the document. This appendix is included to provide a connection 
from discussions on the list to the requirements of Section 8, but it 
is not intended to introduce any new requirements beyond those 
presented in Sections 5 through 8. 


8.1. PRESENCE INFORMATION 


In the case of PRESENCE INFORMATION, the controlling PRINCIPAL’s 
privacy interests are paramount; we agreed that "polite blocking" 
(denying without saying that the subscription is denied, or providing 
false information) should be possible. 


8.1.1. Subscription 


When a user Alice subscribes to another person, Bob’s presence info, 
Alice expects: 


Al. the PRESENTITY’s PRINCIPAL, B, is identifiable and authenticated 


Discussion: Stands as a requirement. Note that the protocol 
should provide Alice the capability of authenticating, without 
requiring that Alice authenticate every SUBSCRIPTION. This 
caveat is made necessary by performance concerns, among others, 
and applies to many of the other requirements derived below. 
[Requirement 5.1.1] 


A2. no third party will know that A has subscribed to B. 


Discussion: This is somewhat unreasonable to enforce as is. For 
example, in some topologies, nothing can prevent someone doing 
traffic analysis to deduce that A has subscribed to B. We should 
merely require that the protocol not expose subscription 
information in any obvious manner. [Requirement 5.1.2] 
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A3. A has the capability to subscribe to B’s presence without B’s 
knowledge, if B permits anonymous subscriptions. 


Discussion: An "anonymous subscription" above can have two 
implications - (i) B may allow an unauthenticated subscription by 
A, and (ii) B may be unaware of A’s stated identity. Requirement 
(i) is reasonable [Requirement 8.1.3], but (ii) doesn’t appear to 
be a core requirement -- it can be adequately simulated via a 
subscription pseudonym. 


A4. A will accurately receive what B chooses to disclose to A 
regarding B’s presence. 


Discussion: Stands as a requirement, with the "optional" 
caveat. [Requirement 8.1.4] 


A5. B will inform A if B refuses A’s subscription 
Discussion: Stands as a requirement. [Requirement 5.1.5] 


A6. No third party, C can force A to subscribe to B’s presence 
without A’s consent. 


Discussion: Stands as a requirement. [Requirement 5.1.6] 


A7. A can cancel her subscription to B’s presence at any time and for 
any reason. When A does so, she will receive no further information 
about B’s presence information. 


Discussion: This essentially stands. However, implementations 
may have to contend with a timing window where A receives, after 
sending her cancellation request, a notification sent by B before 
B received the cancellation request. Therefore, the requirement 
should focus on B’s ceasing to send presence information, rather 
than A’s ceasing to receive it. [Requirement 5.1.7] 


A8. no third party, C, can cancel A’s subscription to B. 


Discussion: Stands, although the administrative exception does 
apply. [Requirement 5.1.8] 


A9. A is notified if her subscription to B is cancelled for any 
reason. 


Discussion: Although the intent is reasonable, there are a number 
of scenarios (e.g. overburdened server, clogged network, server 
crash) where delivering a notification to A of the cancellation 
is undesirable or impossible. Therefore, the service should make 
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an attempt to inform, but this is not required. [Requirement 
Sots | 
Bob expects: 


Bl. B will be informed that A subscribed to B’s presence information, 
as long as A has not subscribed anonymously. 


Discussion: This essentially stands. However, B can also choose 
to determine A’s subscription after the fact. [Requirement 
yak 610] 


B2. A is identifiable and authenticated. 

Discussion: This stands as a requirement. [Requirement 5.1.11] 
B3. B can prevent a particular user, D, from subscribing. 

Discussion: This stands as a requirement. [Requirement 5.1.12] 
B4. B can prevent anonymous users from subscribing. 

Discussion: This stands as a requirement. [Requirement 5.1.13] 


B5. B’s presence information is not republished by A to a third 
party, E, who does not. 


Discussion: This is practically impossible to enforce, so it is 
omitted from the requirement set. 


B6. B can deny A’s subscription without letting A know that she’s 
been blocked. 


Discussion: This "polite blocking" capability essentially stands; 
accepting a "denied" subscription should bear no implication on 
servicing it for status notifications. [Requirement 5.1.14] 
B7. B can cancel A’s subscription at will. 
Discussion: Stands as a requirement. [Requirement 5.1.15] 
Charlie, bob’s network administrator expects: 
C1. C knows who is subscribed to B at all times. 
Discussion: Administrators should be able to determine who is 


subscribed, but needn’t be continuously informed of the list of 
subscribers. Also, in some cases user agents (e.g. proxies) may 
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have subscribed on behalf of users, and in these cases the 
administrator can only determine the identity of these agents, 
not their users. [Requirement 5.1.16] 


C2. C can manage all aspects of A’s presence information. 
Discussion: This stands as a requirement. [Requirement 5.1.17] 


C3. C can control who can access A’s presence information and 
exchange instant messages with A. 


Discussion: This stands in principle, but C should be able to 
waive these capabilities if C desires. [Requirement 5.1.18] 


8.1.2. Publication 
The publisher of status information, Bob, expects: 


Bl. That information about B is not provided to any entity without 
B’s knowledge and consent. 


Discussion: This is nearly impossible to accomplish, so it is 
omitted from the requirements. 


8.1.3. Publication for Notification 
When information is published for notification, B expects: 


Bl. only a person being sent a notification, A, can read the 
notification. 


Discussion: Stands as a requirement. [Requirement 5.2.1] 
B2. A reliably receives all notifications intended for her. 


Discussion: This stands, although "Reliably" is a little strong 
(e.g. network outages, etc.). [Requirement 5.2.2] 


B3. B can prevent A from receiving notifications, even if A is 
ordinarily permitted to see such notifications. This is a variation 
on “polite blocking." 


Discussion: This stands as a requirement. Also incorporated into 


this requirement is the notifications equivalent of the next 
expectation, B4. [Requirement 5.2.3] 
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B4. B can provide two interested parties A and E with different 
status information at the same time. (B could represent the same 
event differently to different people.) 


Discussion: This stands as a requirement; it has been 
incorporated into the corresponding requirement for B3 above. 


B5. B expects that malicious C cannot spoof notification messages 
about B. 


Discussion: Stands in principle, but it should be optional for B. 
[Requirement 5.2.4] 


8.1.4. Receiving a Notification 
When Alice receives a notification, the recipient, Alice, expects: 
Al. That the notification information is accurate, truthful. 
Discussion: Stands in principle, although being "truthful" can’t 
be a requirement, and the verification is optional for Alice. 
[Requirement 5.3.1] 
A2. That information about subscriptions remains private; people do 
not learn that A’s subscription to B’s information exists by watching 
notifications occur. 
Discussion: This is omitted from the requirements, as traffic 
analysis, even of encrypted traffic, can convey this information 


in some situations. 


A3. That she only receives notifications of things she’s subscribed 
to. 


Discussion: Stands as a requirement. [Requirement 5.3.2] 
A4. Notifications come from the apparent sender, B. 


Discussion: Stands in principle, although the verification should 
be optional for A. [Requirement 5.3.3] 


A5. A can tell the difference between a message generated by the 
user, and a message legitimately generated by the agent on behalf of 
the user. 


Discussion: This could be quite difficult to enforce and could 


unduly restrict usage scenarios; this is omitted from the 
requirements. 


Day, et al. Informational [Page 20] 


RFC 2779 Instant Messaging/Presence Protocol February 2000 


A6. That information given by agents on behalf of users can also be 
expected to be truthful, complete, and legitimately offered; the user 
permitted the agent to publish these notifications. 


Discussion: This is difficult to enforce and is omitted from the 
requirements. 


A7. A can prove that a notification from B was delivered in a timely 
fashion and can prove exactly how long the message took to be 
delivered. 


Discussion: This is difficult to enforce and is omitted from the 
requirements. For example, such proof may entail global time 
synchronization mechanisms (since any system clocks have 
associated unreliability), which is outside the scope of this 
effort. 


A8. A can prove that B was indeed the sender of a given message. 


Discussion: This is a duplication of expectation A4 above and is 
reflected in the corresponding requirement 5.3.3. 


8.2. INSTANT MESSAGEs 
8.2.1. Named Instant Messaging 
When a user Alice sends an instant message M to another user Bob: 
Alice expects that she: 
Al. will receive notification of non-delivery 
Discussion: Stands as a requirement. [Requirement 5.4.1] 
Alice expects that Bob: 
Bl. will receive the message 


Discussion: covered by Al and is reflected in the corresponding 
requirement 5.4.1. 


B2. will receive the message quickly 
Discussion: Stands as a requirement, although this is also 


covered elsewhere (in the non-security requirements), so this is 
omitted from the security requirements. 
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B3. will receive the message only once 
Discussion: Stands as a requirement. [Requirement 5.4.2] 
B4. will be able to verify that Alice sent the message 
Discussion: Stands as a requirement. [Requirement 5.4.3] 
B5. will not know whether there were BCCs 
Discussion: Emulating e-mail conventions and social protocols is 


not a core goal of this effort, and therefore references to 
standard mail fields are omitted from the requirements. 


B6. will be able to reply to the message 


Discussion: Stands in principle; the recipient should be able to 
reply via an instant message. [Requirement 5.4.4] 


B7. will know if he was a bcc recipient 
Discussion: Omitted, as noted above. 


B8. will not be able to determine any information about A (such as 
her location or IP address) without A's knowledge and consent. 


Discussion: "Any information about A" is too general; the 

requirement should focus on IP address. Further, "without A's 

knowledge and consent" may be overkill. [Requirement 5.4.5] 
Alice expects that no other user Charlie will be able to: 


Cl. see the content of M 


Discussion: Stands in principle, although this should not be 
mandated for all IM communication. [Requirement 5.4.6] 


C2. tamper with M 


Discussion: Stands, with the same caveat as above. 
[Requirement 5.4.7] 


C3. know that M was sent 


Discussion: It is impossible to prevent traffic analysis, and 
this is therefore omitted from the requirements. 
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When a user Bob receives an instant message M from another user 
Alice: 

Bob expects that Bob: 
D1. will be able to read M 
Discussion: Stands as a requirement. [Requirement 5.4.8] 


D2. will be able to verify M’s authenticity (both Temporal and the 
sender’s identity) 


Discussion: As noted earlier, it is not reasonable to directly 
require temporal checks. The protocol should, however, allow 
signing messages using existing standards for signing. 
[Requirement 5.4.9] 

D3. will be able to verify M’s integrity 
Discussion: Stands as a requirement. [Requirement 5.4.10] 

D4. will be able to prevent A from sending him future messages 
Discussion: Stands as a requirement. [Requirement 5.4.11] 


Bob expects that Alice: 


El. intended to send the message to Bob 


Discussion: This is covered by the corresponding requirement 
5.4.6 for Cl above. 


E2. informed Bob of all CCs. 


Discussion: As noted earlier, references to cc:’s are omitted 
from the requirements. 


8.2.2. Anonymous Instant Messaging 


Discussion: Anonymous instant messaging, as in "hiding the 
identity of the sender", is not deemed to be a core requirement 
of the protocol and references to it are therefore omitted from 
the requirements. Implementations may provide facilities for 
anonymous messaging if they wish, in ways that are consistent 
with the other requirements. 


When a user Alice sends an anonymous instant message to another user 
Bob: 
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Alice expects that Bob: 

Bl. will receive the message 

B2. will receive the message quickly 
B3. will receive the message only once 


AB4.1. cannot know Alice sent it 


named user 


AB4.3 may not allow anonymous IMs 

B5. will not know whether there were BCCs 

B6. will be able to reply to the message 

Alice expects that she: 

C1. will receive notification of non-delivery 
AC2. will receive an error if the IM was refused 
Bob expects that he: 


D1. will be able to read M 


February 2000 


AB4.2. will know that the IM is anonymous, and not from a specific 


D2. will be able to verify M's authenticity (both temporal and the 


sender's identity) 
D3. will be able to verify M's integrity 


AD4. will know if an IM was sent anonymously 


AD5. will be able to automatically discard anonymous IM if desired 


AD6. will be able to control whether an error is sent to Alice if M 


is discarded. 
8.2.3. Administrator Expectations 


Charlie, Alice’s network administrator expects: 


C1. that C will be able to send A instant messages at any time. 


C2. that A will receive any message he sends while A is online. 
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C3. that A will not be able to refuse delivery of any instant 
messages sent by C. 


Discussion for C1-C3: It is not clear this needs to be specially 
handled at the protocol level; Administrators may accomplish the 


above objectives through other means. For example, an 
administrator may send a message to a user through the normal 
mechanisms. This is therefore omitted from the requirements. 
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